## Summary

Adds a `publish-on-release.yml` workflow that fires on the `release:
published` event, so a human manually creating a GitHub release (with
`gh release create v0.X.Y`) can drive the PyPI publish through CI
without `workflow_dispatch` and without resorting to local `twine
upload`.

## Why

Release-please got stuck on PR #50 with `autorelease: pending` after the
merge. Every subsequent `release.yml` run aborts at the release-please
step (`untagged, merged release PRs outstanding`), so the existing
publish path can't fire. PyPI is on 0.2.19, manifest+pyproject on `main`
say 0.2.20.

Manual recovery options today are:
1. Run `gh release create v0.2.20 ...` to create the release. **But**
the existing publish job in `release.yml` is gated on release-please's
outputs, not on release events. Manual release alone doesn't trigger
publish.
2. Local `twine upload` against PyPI. Bypasses CI entirely. No.
3. `workflow_dispatch` to bypass the release-please gate. **But**
`workflow_dispatch` is what got us into the cli.deepgram.com vs PyPI
skew the other day. Removed in #54.

This PR adds a fourth option, gated on real release artifacts.

## How it works

`publish-on-release.yml` triggers on `release: published`. When fired:

1. checks out the released tag
2. installs python + build tools
3. runs `make build` and `make verify-packages`
4. uploads to PyPI via the same `pypa/gh-action-pypi-publish` action and
`PYPI_API_TOKEN` secret as the existing publish job

It only fires for root tags (`startsWith(github.event.release.tag_name,
'v')`) so sub-package tags like `deepctl-cmd-listen-v0.0.10` continue to
flow through `release.yml`.

## No double-publish

GITHUB_TOKEN-created releases (which is how release-please's
create-release step works) do **not** trigger downstream workflows.
GitHub Actions intentionally blocks that loop. So when release-please's
normal flow works, `release.yml`'s existing publish job handles it as
before, and this workflow stays asleep. This workflow only fires for
human-created releases.

(Same dynamic that the existing `web-production.yml` comment notes for
the workflow_call vs release-published trigger choice.)

## Recovery procedure for v0.2.20

After this lands:

1. `gh release create v0.2.20 --target 2fab886 --title v0.2.20 --notes
"$(curl -s
'https://raw.githubusercontent.com/deepgram/cli/2fab886/CHANGELOG.md' |
sed -n '/^## \[0.2.20/,/^## /{/^## \[0.2.20/!{/^## /d}};p')"`
2. that fires this workflow → builds + uploads to PyPI
3. relabel `#50`: `autorelease: pending` → `autorelease: tagged`
4. release-please unsticks for future runs

## What this PR doesn't do

- doesn't fix release-please's stuck state (manual relabel needed once
tag exists)
- doesn't trigger any release itself (no `workflow_dispatch`, no
scheduled run)
- doesn't touch `release.yml` (the normal flow continues unchanged)
- doesn't extend `bump-brew-formula` to fire on manual recovery releases
(separate concern; brew bump is currently broken anyway due to the
`deepgram-robot` 403 issue)

## Verification

- `python -c "import yaml;
yaml.safe_load(open('.github/workflows/publish-on-release.yml'))"`
parses cleanly
- only one job, gated on root `v*` tag
- uses the same SHA-pinned actions as the existing `release.yml` publish
job (`actions/checkout@34e1148...`, `actions/setup-python@a309ff8...`,
`pypa/gh-action-pypi-publish@ed0c539...`)